13. září 2025Čeština

Hloubkový pohled na analytiku porušení Content Security Policy (CSP) na frontendu se zaměřením na analýzu bezpečnostních událostí, monitorování a strategie zmírňování pro globální webové aplikace.

Analytika porušení Content Security Policy na frontendu: Analýza bezpečnostních událostí

V dnešním prostředí plném hrozeb je bezpečnost webových aplikací prvořadá. Jednou z nejúčinnějších obran proti různým útokům, včetně Cross-Site Scripting (XSS), je Content Security Policy (CSP). CSP je přidaná vrstva zabezpečení, která pomáhá detekovat a zmírňovat určité typy útoků, včetně XSS a útoků typu data injection. Tyto útoky se používají ke všemu, od krádeže dat, přes znehodnocení stránek, až po distribuci malwaru.

Pouhá implementace CSP však nestačí. Je třeba aktivně monitorovat a analyzovat porušení CSP, abyste pochopili bezpečnostní stav vaší aplikace, identifikovali potenciální zranitelnosti a doladili svou politiku. Tento článek poskytuje komplexního průvodce analytikou porušení CSP na frontendu se zaměřením na analýzu bezpečnostních událostí a praktické strategie pro zlepšení. Prozkoumáme globální dopady a osvědčené postupy pro správu CSP v různých vývojových prostředích.

Co je Content Security Policy (CSP)?

Content Security Policy (CSP) je bezpečnostní standard definovaný jako hlavička HTTP odpovědi, která umožňuje webovým vývojářům kontrolovat, jaké zdroje může uživatelský agent pro danou stránku načíst. Definováním whitelistu důvěryhodných zdrojů můžete výrazně snížit riziko vložení škodlivého obsahu do vaší webové aplikace. CSP funguje tak, že instruuje prohlížeč, aby spouštěl skripty, načítal obrázky, styly a další zdroje pouze z určených zdrojů.

Klíčové direktivy v CSP:

`default-src`: Slouží jako záložní direktiva pro ostatní fetch direktivy. Pokud není definován konkrétní typ zdroje, použije se tato direktiva.
`script-src`: Specifikuje platné zdroje pro JavaScript.
`style-src`: Specifikuje platné zdroje pro CSS styly.
`img-src`: Specifikuje platné zdroje pro obrázky.
`connect-src`: Specifikuje platné zdroje pro spojení typu fetch, XMLHttpRequest, WebSockets a EventSource.
`font-src`: Specifikuje platné zdroje pro písma.
`media-src`: Specifikuje platné zdroje pro načítání médií jako audio a video.
`object-src`: Specifikuje platné zdroje pro pluginy jako Flash. (Obecně je nejlepší pluginy zcela zakázat nastavením na 'none'.)
`base-uri`: Specifikuje platné URL, které mohou být použity v elementu `` dokumentu.
`form-action`: Specifikuje platné koncové body pro odesílání formulářů.
`frame-ancestors`: Specifikuje platné rodičovské prvky, které mohou vkládat stránku pomocí ``, ``, `<object>`, `<embed>` nebo `<applet>`.</li> <li>`report-uri` (Zastaralé): Specifikuje URL, na kterou má prohlížeč zasílat hlášení o porušeních CSP. Zvažte místo toho použití `report-to`.</li> <li>`report-to`: Specifikuje pojmenovaný koncový bod nakonfigurovaný pomocí hlavičky `Report-To`, který by měl prohlížeč použít k zasílání hlášení o porušeních CSP. Toto je moderní náhrada za `report-uri`.</li> <li>`upgrade-insecure-requests`: Dává pokyn uživatelským agentům, aby se všemi nezabezpečenými URL adresami webu (těmi, které jsou poskytovány přes HTTP) zacházeli, jako by byly nahrazeny zabezpečenými URL (těmi, které jsou poskytovány přes HTTPS). Tato direktiva je určena pro weby, které přecházejí na HTTPS.</li> </ul> Příklad hlavičky CSP: `Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:; report-to csp-endpoint;` Tato politika umožňuje načítání zdrojů ze stejného původu (`'self'`), JavaScriptu z `https://example.com`, inline stylů, obrázků ze stejného původu a data URI a specifikuje koncový bod pro hlášení s názvem `csp-endpoint` (nakonfigurovaný pomocí hlavičky `Report-To`). <h2>Proč je analytika porušení CSP důležitá?</h2> I když správně nakonfigurovaná CSP může výrazně zvýšit bezpečnost, její účinnost závisí na aktivním monitorování a analýze hlášení o porušeních. Zanedbávání těchto hlášení může vést k falešnému pocitu bezpečí a promarněným příležitostem k řešení skutečných zranitelností. Zde je důvod, proč je analytika porušení CSP klíčová: <ul> <li>Identifikace pokusů o XSS: Porušení CSP často naznačují pokusy o útoky XSS. Analýza těchto hlášení vám pomůže detekovat a reagovat na škodlivou aktivitu dříve, než může způsobit škodu.</li> <li>Odhalení slabin politiky: Hlášení o porušeních odhalují mezery ve vaší konfiguraci CSP. Identifikací toho, které zdroje jsou blokovány, můžete svou politiku zdokonalit, aby byla účinnější, aniž byste narušili legitimní funkčnost.</li> <li>Ladění problémů v legitimním kódu: Někdy jsou porušení způsobena legitimním kódem, který neúmyslně porušuje CSP. Analýza hlášení vám pomůže tyto problémy identifikovat a opravit. Například vývojář může omylem zahrnout inline skript nebo CSS pravidlo, které by mohlo být blokováno přísnou CSP.</li> <li>Monitorování integrací třetích stran: Knihovny a služby třetích stran mohou představovat bezpečnostní rizika. Hlášení o porušeních CSP poskytují vhled do chování těchto integrací a pomáhají vám zajistit, že jsou v souladu s vašimi bezpečnostními politikami. Mnoho organizací nyní vyžaduje, aby dodavatelé třetích stran poskytovali informace o souladu s CSP jako součást svého bezpečnostního hodnocení.</li> <li>Soulad s předpisy a audit: Mnoho nařízení a průmyslových standardů vyžaduje robustní bezpečnostní opatření. CSP a její monitorování mohou být klíčovou součástí prokazování souladu. Udržování záznamů o porušeních CSP a vaší reakci na ně je cenné během bezpečnostních auditů.</li> </ul> <h2>Nastavení hlášení CSP</h2> Než budete moci analyzovat porušení CSP, musíte nakonfigurovat váš server tak, aby posílal hlášení na určený koncový bod. Moderní hlášení CSP využívá hlavičku `Report-To`, která poskytuje větší flexibilitu a spolehlivost ve srovnání se zastaralou direktivou `report-uri`. Krok 1: Konfigurace hlavičky `Report-To`: Hlavička `Report-To` definuje jeden nebo více koncových bodů pro hlášení. Každý koncový bod má název, URL a volitelný čas vypršení platnosti. Příklad: `Report-To: {"group":"csp-endpoint","max_age":31536000,"endpoints":[{"url":"https://your-reporting-service.com/csp-report"}],"include_subdomains":true}` <ul> <li>`group`: Název pro koncový bod hlášení (např. "csp-endpoint"). Na tento název se odkazuje v direktivě `report-to` hlavičky CSP.</li> <li>`max_age`: Životnost konfigurace koncového bodu v sekundách. Prohlížeč si konfiguraci koncového bodu ukládá do mezipaměti po tuto dobu. Běžná hodnota je 31536000 sekund (1 rok).</li> <li>`endpoints`: Pole objektů koncových bodů. Každý objekt specifikuje URL, kam mají být hlášení odesílána. Můžete nakonfigurovat více koncových bodů pro redundanci.</li> <li>`include_subdomains` (Volitelné): Pokud je nastaveno na `true`, konfigurace hlášení se vztahuje na všechny subdomény dané domény.</li> </ul> Krok 2: Konfigurace hlavičky `Content-Security-Policy`: Hlavička `Content-Security-Policy` definuje vaši politiku CSP a zahrnuje direktivu `report-to`, která odkazuje na koncový bod hlášení definovaný v hlavičce `Report-To`. Příklad: `Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; report-to csp-endpoint;` Krok 3: Nastavení koncového bodu pro hlášení: Musíte vytvořit serverový koncový bod, který bude přijímat a zpracovávat hlášení o porušeních CSP. Tento koncový bod by měl být schopen zpracovávat data ve formátu JSON a ukládat hlášení pro analýzu. Přesná implementace závisí na vaší serverové technologii (např. Node.js, Python, Java). Příklad (Node.js s Expressem): <pre> <code> const express = require('express'); const bodyParser = require('body-parser'); const app = express(); app.use(bodyParser.json()); app.post('/csp-report', (req, res) => { const report = req.body['csp-report']; console.log('CSP Violation Report:', report); // Uložte hlášení do databáze nebo log souboru res.status(204).end(); // Odpovězte stavem 204 No Content }); const port = 3000; app.listen(port, () => { console.log(`Server naslouchá na portu ${port}`); }); </code> </pre> Krok 4: Zvažte použití `Content-Security-Policy-Report-Only` pro testování: Před vynucením CSP je dobrým zvykem otestovat ji v režimu pouze pro hlášení. To vám umožní monitorovat porušení bez blokování jakýchkoli zdrojů. Použijte hlavičku `Content-Security-Policy-Report-Only` místo `Content-Security-Policy`. Porušení budou hlášena na váš koncový bod, ale prohlížeč politiku nevynutí. Příklad: `Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://example.com; report-to csp-endpoint;` <h2>Analýza hlášení o porušeních CSP</h2> Jakmile nastavíte hlášení CSP, začnete dostávat hlášení o porušeních. Tato hlášení jsou objekty JSON obsahující informace o porušení. Struktura hlášení je definována specifikací CSP. Příklad hlášení o porušení CSP: <pre> <code> { "csp-report": { "document-uri": "https://example.com/page.html", "referrer": "https://attacker.com", "violated-directive": "script-src 'self' https://example.com", "effective-directive": "script-src", "original-policy": "default-src 'self'; script-src 'self' https://example.com; report-to csp-endpoint;", "disposition": "report", "blocked-uri": "https://attacker.com/evil.js", "status-code": 200, "script-sample": "", "source-file": "https://attacker.com/evil.js", "line-number": 1, "column-number": 1 } } </code> </pre> Klíčová pole v hlášení o porušení CSP: <ul> <li>`document-uri`: URI dokumentu, ve kterém k porušení došlo.</li> <li>`referrer`: URI odkazující stránky (pokud existuje).</li> <li>`violated-directive`: Direktivy CSP, která byla porušena.</li> <li>`effective-directive`: Direktivy, která byla skutečně aplikována, s přihlédnutím k záložním mechanismům.</li> <li>`original-policy`: Kompletní politika CSP, která byla v platnosti.</li> <li>`disposition`: Označuje, zda bylo porušení vynuceno (`"enforce"`) nebo pouze hlášeno (`"report"`).</li> <li>`blocked-uri`: URI zdroje, který byl zablokován.</li> <li>`status-code`: HTTP stavový kód zablokovaného zdroje.</li> <li>`script-sample`: Úryvek zablokovaného skriptu (pokud je k dispozici). Prohlížeče mohou z bezpečnostních důvodů části ukázky skriptu redigovat.</li> <li>`source-file`: Zdrojový soubor, kde k porušení došlo (pokud je k dispozici).</li> <li>`line-number`: Číslo řádku ve zdrojovém souboru, kde k porušení došlo.</li> <li>`column-number`: Číslo sloupce ve zdrojovém souboru, kde k porušení došlo.</li> </ul> <h2>Kroky pro efektivní analýzu bezpečnostních událostí</h2> Analýza hlášení o porušeních CSP je nepřetržitý proces, který vyžaduje strukturovaný přístup. Zde je podrobný průvodce, jak efektivně analyzovat bezpečnostní události na základě dat o porušeních CSP: <ol> <li>Prioritizujte hlášení podle závažnosti: Zaměřte se na porušení, která naznačují potenciální útoky XSS nebo jiná vážná bezpečnostní rizika. Například porušení s blokovaným URI z neznámého nebo nedůvěryhodného zdroje by měla být okamžitě prošetřena.</li> <li>Identifikujte hlavní příčinu: Zjistěte, proč k porušení došlo. Jedná se o legitimní zdroj, který je blokován kvůli chybné konfiguraci, nebo se jedná o škodlivý skript, který se pokouší spustit? Podívejte se na pole `blocked-uri`, `violated-directive` a `referrer`, abyste porozuměli kontextu porušení.</li> <li>Kategorizujte porušení: Seskupte porušení do kategorií na základě jejich hlavní příčiny. To vám pomůže identifikovat vzory a prioritizovat nápravná opatření. Běžné kategorie zahrnují:</li> <ul> <li>Chybné konfigurace: Porušení způsobená nesprávnými direktivami CSP nebo chybějícími výjimkami.</li> <li>Problémy v legitimním kódu: Porušení způsobená inline skripty nebo styly, nebo kódem, který porušuje CSP.</li> <li>Problémy třetích stran: Porušení způsobená knihovnami nebo službami třetích stran.</li> <li>Pokusy o XSS: Porušení, která naznačují potenciální útoky XSS.</li> </ul> <li>Prošetřete podezřelou aktivitu: Pokud se porušení jeví jako pokus o XSS, důkladně ho prošetřete. Podívejte se na pole `referrer`, `blocked-uri` a `script-sample`, abyste pochopili záměr útočníka. Zkontrolujte logy serveru a další nástroje pro monitorování bezpečnosti kvůli související aktivitě.</li> <li>Napravte porušení: Na základě hlavní příčiny podnikněte kroky k nápravě porušení. To může zahrnovat: <ul> <li>Aktualizace CSP: Upravte CSP tak, aby povolovala legitimní zdroje, které jsou blokovány. Dávejte pozor, abyste politiku zbytečně neoslabili.</li> <li>Oprava kódu: Odstraňte inline skripty nebo styly, nebo upravte kód tak, aby byl v souladu s CSP.</li> <li>Aktualizace knihoven třetích stran: Aktualizujte knihovny třetích stran na nejnovější verze, které mohou obsahovat bezpečnostní opravy.</li> <li>Blokování škodlivé aktivity: Blokujte škodlivé požadavky nebo uživatele na základě informací v hlášeních o porušeních.</li> </ul> </li> <li>Otestujte své změny: Po provedení změn v CSP nebo kódu důkladně otestujte svou aplikaci, abyste se ujistili, že změny nezpůsobily žádné nové problémy. Použijte hlavičku `Content-Security-Policy-Report-Only` k testování změn v nevynucovacím režimu.</li> <li>Zdokumentujte svá zjištění: Zdokumentujte porušení, jejich hlavní příčiny a nápravné kroky, které jste podnikli. Tyto informace budou cenné pro budoucí analýzu a pro účely souladu s předpisy.</li> <li>Automatizujte proces analýzy: Zvažte použití automatizovaných nástrojů pro analýzu hlášení o porušeních CSP. Tyto nástroje vám mohou pomoci identifikovat vzory, prioritizovat porušení a generovat reporty.</li> </ol> <h2>Praktické příklady a scénáře</h2> Pro ilustraci procesu analýzy hlášení o porušeních CSP se podívejme na několik praktických příkladů: Scénář 1: Blokování inline skriptů Hlášení o porušení: <pre> <code> { "csp-report": { "document-uri": "https://example.com/page.html", "violated-directive": "script-src 'self' https://example.com", "blocked-uri": "inline", "script-sample": "<script>alert('Hello');</script>" } } </code> </pre> Analýza: Toto porušení naznačuje, že CSP blokuje inline skript. Jedná se o běžný scénář, protože inline skripty jsou často považovány za bezpečnostní riziko. Pole `script-sample` ukazuje obsah zablokovaného skriptu. Náprava: Nejlepším řešením je přesunout skript do samostatného souboru a načíst ho z důvěryhodného zdroje. Alternativně můžete použít nonce nebo hash k povolení konkrétních inline skriptů. Tyto metody jsou však obecně méně bezpečné než přesunutí skriptu do samostatného souboru. Scénář 2: Blokování knihovny třetí strany Hlášení o porušení: <pre> <code> { "csp-report": { "document-uri": "https://example.com/page.html", "violated-directive": "script-src 'self' https://example.com", "blocked-uri": "https://cdn.example.com/library.js" } } </code> </pre> Analýza: Toto porušení naznačuje, že CSP blokuje knihovnu třetí strany hostovanou na `https://cdn.example.com`. To může být způsobeno chybnou konfigurací nebo změnou umístění knihovny. Náprava: Zkontrolujte CSP, abyste se ujistili, že `https://cdn.example.com` je zahrnuta v direktivě `script-src`. Pokud ano, ověřte, že je knihovna stále hostována na zadané URL. Pokud se knihovna přesunula, aktualizujte CSP odpovídajícím způsobem. Scénář 3: Potenciální útok XSS Hlášení o porušení: <pre> <code> { "csp-report": { "document-uri": "https://example.com/page.html", "referrer": "https://attacker.com", "violated-directive": "script-src 'self' https://example.com", "blocked-uri": "https://attacker.com/evil.js" } } </code> </pre> Analýza: Toto porušení je znepokojivější, protože naznačuje potenciální útok XSS. Pole `referrer` ukazuje, že požadavek pochází z `https://attacker.com`, a pole `blocked-uri` ukazuje, že CSP zablokovala skript ze stejné domény. To silně naznačuje, že se útočník pokouší vložit škodlivý kód do vaší aplikace. Náprava: Okamžitě prošetřete porušení. Zkontrolujte logy serveru kvůli související aktivitě. Zablokujte IP adresu útočníka a podnikněte kroky k zabránění budoucím útokům. Zkontrolujte svůj kód kvůli potenciálním zranitelnostem, které by mohly umožnit útoky XSS. Zvažte implementaci dalších bezpečnostních opatření, jako je validace vstupu a kódování výstupu. <h2>Nástroje pro analýzu porušení CSP</h2> Několik nástrojů vám může pomoci automatizovat a zjednodušit proces analýzy hlášení o porušeních CSP. Tyto nástroje mohou poskytovat funkce jako: <ul> <li>Agregace a vizualizace: Agregujte hlášení o porušeních z více zdrojů a vizualizujte data pro identifikaci trendů a vzorů.</li> <li>Filtrování a vyhledávání: Filtrujte a prohledávejte hlášení na základě různých kritérií, jako jsou `document-uri`, `violated-directive` a `blocked-uri`.</li> <li>Upozornění: Odesílejte upozornění, když jsou detekována podezřelá porušení.</li> <li>Reportování: Generujte reporty o porušeních CSP pro účely souladu s předpisy a auditu.</li> <li>Integrace se systémy pro správu bezpečnostních informací a událostí (SIEM): Přeposílejte hlášení o porušeních CSP do systémů SIEM pro centralizované monitorování bezpečnosti.</li> </ul> Mezi populární nástroje pro analýzu porušení CSP patří: <ul> <li>Report URI: Specializovaná služba pro hlášení CSP, která poskytuje podrobnou analýzu a vizualizaci hlášení o porušeních.</li> <li>Sentry: Populární platforma pro sledování chyb a monitorování výkonu, kterou lze také použít k monitorování porušení CSP.</li> <li>Google Security Analytics: Cloudová platforma pro bezpečnostní analytiku, která dokáže analyzovat hlášení o porušeních CSP spolu s dalšími bezpečnostními daty.</li> <li>Vlastní řešení: Můžete si také vytvořit vlastní nástroje pro analýzu porušení CSP pomocí open-source knihoven a frameworků.</li> </ul> <h2>Globální aspekty implementace CSP</h2> Při implementaci CSP v globálním kontextu je nezbytné zvážit následující: <ul> <li>Sítě pro doručování obsahu (CDN): Pokud vaše aplikace používá CDN k doručování statických zdrojů, ujistěte se, že jsou domény CDN zahrnuty v CSP. CDN mají často regionální variace (např. `cdn.example.com` pro Severní Ameriku, `cdn.example.eu` pro Evropu). Vaše CSP by měla tyto variace zohlednit.</li> <li>Služby třetích stran: Mnoho webových stránek se spoléhá na služby třetích stran, jako jsou analytické nástroje, reklamní sítě a widgety sociálních médií. Ujistěte se, že domény používané těmito službami jsou zahrnuty v CSP. Pravidelně kontrolujte své integrace třetích stran, abyste identifikovali jakékoli nové nebo změněné domény.</li> <li>Lokalizace: Pokud vaše aplikace podporuje více jazyků nebo regionů, může být nutné CSP upravit tak, aby vyhovovala různým zdrojům nebo doménám. Například budete možná muset povolit písma nebo obrázky z různých regionálních CDN.</li> <li>Regionální předpisy: Některé země mají specifické předpisy týkající se ochrany osobních údajů a bezpečnosti. Ujistěte se, že vaše CSP je v souladu s těmito předpisy. Například Obecné nařízení o ochraně osobních údajů (GDPR) v Evropské unii vyžaduje ochranu osobních údajů občanů EU.</li> <li>Testování v různých regionech: Otestujte svou CSP v různých regionech, abyste se ujistili, že funguje správně a neblokuje žádné legitimní zdroje. K ověření politiky použijte vývojářské nástroje prohlížeče nebo online validátory CSP.</li> </ul> <h2>Osvědčené postupy pro správu CSP</h2> Abyste zajistili trvalou účinnost vaší CSP, dodržujte tyto osvědčené postupy: <ul> <li>Začněte s přísnou politikou: Začněte s přísnou politikou, která povoluje pouze zdroje z důvěryhodných zdrojů. Postupně politiku uvolňujte podle potřeby na základě hlášení o porušeních.</li> <li>Používejte nonce nebo hashe pro inline skripty a styly: Pokud musíte použít inline skripty nebo styly, použijte nonce nebo hashe k povolení konkrétních instancí. To je bezpečnější než povolení všech inline skriptů nebo stylů.</li> <li>Vyhněte se `unsafe-inline` a `unsafe-eval`: Tyto direktivy výrazně oslabují CSP a měly by být pokud možno nepoužívány.</li> <li>Pravidelně kontrolujte a aktualizujte CSP: Pravidelně kontrolujte CSP, abyste se ujistili, že je stále účinná a že odráží jakékoli změny ve vaší aplikaci nebo integracích třetích stran.</li> <li>Automatizujte proces nasazení CSP: Automatizujte proces nasazování změn CSP, abyste zajistili konzistenci a snížili riziko chyb.</li> <li>Monitorujte hlášení o porušeních CSP: Pravidelně monitorujte hlášení o porušeních CSP, abyste identifikovali potenciální bezpečnostní rizika a doladili politiku.</li> <li>Vzdělávejte svůj vývojový tým: Vzdělávejte svůj vývojový tým o CSP a její důležitosti. Ujistěte se, že rozumí, jak psát kód, který je v souladu s CSP.</li> </ul> <h2>Budoucnost CSP</h2> Standard Content Security Policy se neustále vyvíjí, aby řešil nové bezpečnostní výzvy. Mezi nově vznikající trendy v CSP patří: <ul> <li>Trusted Types: Nové API, které pomáhá předcházet útokům XSS založeným na DOM tím, že zajišťuje, aby data vkládaná do DOM byla správně sanitizována.</li> <li>Feature Policy: Mechanismus pro kontrolu, které funkce prohlížeče jsou pro webovou stránku dostupné. To může pomoci snížit útočnou plochu vaší aplikace.</li> <li>Subresource Integrity (SRI): Mechanismus pro ověření, že soubory načtené z CDN nebyly zmanipulovány.</li> <li>Granulárnější direktivy: Pokračující vývoj specifičtějších a granulárnějších direktiv CSP, které poskytují jemnější kontrolu nad načítáním zdrojů.</li> </ul> <h2>Závěr</h2> Analytika porušení Content Security Policy na frontendu je nezbytnou součástí moderní bezpečnosti webových aplikací. Aktivním monitorováním a analýzou porušení CSP můžete identifikovat potenciální bezpečnostní rizika, doladit svou politiku a chránit svou aplikaci před útoky. Implementace CSP a pečlivá analýza hlášení o porušeních je klíčovým krokem při budování bezpečných a spolehlivých webových aplikací pro globální publikum. Přijetí proaktivního přístupu ke správě CSP, včetně automatizace a vzdělávání týmu, zajišťuje robustní obranu proti vyvíjejícím se hrozbám. Pamatujte, že bezpečnost je nepřetržitý proces a CSP je mocným nástrojem ve vašem arzenálu.</div><footer class="mt-12 pt-8 border-t border-gray-200"><h3 class="text-sm font-semibold text-gray-900 mb-3 dark:text-white/90">Tags:</h3><div class="flex flex-wrap gap-2">Content Security PolicyCSPbezpečnost frontenduhlášení porušeníbezpečnostní analytikawebová bezpečnostXSSbezpečnostní monitoringbezpečnostní událostiochrana datinformační bezpečnostvývoj webu</div></footer></article></div><script>$RS=function(a,b){a=document.getElementById(a);b=document.getElementById(b);for(a.parentNode.removeChild(a);a.firstChild;)b.parentNode.insertBefore(a.firstChild,b);b.parentNode.removeChild(b)};$RS("S:2","P:2")</script><script>$RC("B:1","S:1")</script></body></html>